TMON Debugging
Volume Number: 1
Issue Number: 10
Column Tag: Assembly Language Lab
Debugging Techniques and TMON Review" 
By Paul Snively, Columbus, IN., MacTutor Contributing Editor
I was just reading my Volume 1, No. 4 MacTutor and came across William
Gladnick's letter asking about tips, utilities, and debugging techniques. OK, I'll bite!
MacsBug Snoops the ROMS
As far as useful utilities go, first, get a 512K system. Then get MacNOSY and
TMON (the latter is from TMQ software). These, plus a good assembler (MacASM, in
other words) are all that you really need to do serious Mac hacking.
As for tips, here's one: the Mac ROMs are buggy, and nearly everyone knows it.
What's not so obvious is how to use MacsBug to trace through the ROMs step by step
(rather than treating the A-traps as a single instruction). Wouldn't it be nice to be
able to trace one instruction at a time while in a ROM routine? OK, here's how: write
your application (I assume that you are using one assembler or another). The first
instruction should be:
LABEL BRA LABEL
followed by your program. Assemble the program in the usual way. Install
MacsBug in your system. Double-click your program's icon. The system will seem to
hang, since you told it to BRanch Always to LABEL, which is where the branch is. In
other words, your program is in an infinite loop. Press the interrupt button on your
Mac. MacsBug will be entered with the PC pointing to your BRA instruction. Bump the
PC by two to point past the BRA. Now start tracing your program.
How to Trace the ROM Routines
As you are tracing or stepping through your code with MacsBug, the disassembly
will eventually say something along the lines of "OSTRAP A219" or "TOOLBOX A912
or what have you. STOP! DO NOT TRACE OR STEP! Now, change the value in A7
downward by six bytes. In other words, if A7 is now 00123AC7, change it to
00123AC1. This is to simulate the stack setup caused by the 68000 during exception
processing.
Now, look at the current PC value. Let's say it's 00004E56. Store this address
at A7+2 using the SM command, like this:
SM 00123AC3 00 00 4E 56
Now type PC 401018. You may now continue tracing or what have you.
Essentially, you have done manually what the 68000 would have done automatically
upon encountering the A-trap. 401018 is the address of the Macintosh A-trap
dispatch routine. Observe the code as you trace through it; it's quite interesting. For
example, the main difference between OSTRAPs and TOOLBOX traps is that for
OSTRAPs, which require an I/O buffer address in A0 and return a status code in D0, A0
and D0 must not be saved on the stack across the actual code. Apple accomplished this
by setting bit 11 in all of the TOOLBOX instructions (in other words, the second
hexadecimal digit of a TOOLBOX trap will always be at least 8). The dispatch code at
401018 examines that bit to determine whether or not to save A0 and D0 (and
possibly some other registers) on the stack.
More important, you can watch as the dispatch code determines via a lookup table
where to go in the ROMs, and you can trace through those high-power ROM routines
that we've all come to know and love. Now you can see for yourself exactly how a
window is opened, or what have you.
The ability to trace through the ROMs, coupled with MacNOSY's capability of
outputting labels, as opposed to addresses, makes for a relatively simple way of
learning how the Mac works right down at the nuts and bolts level - which is right up
MacTutor's alley, right, guys?
May all of your hacking - er, excuse me, I mean programming - be bug free!
TMON Thoughts
Some of you may have seen TMQ Software's ad in MacTutor lately. They're
pushing a product called TMON, which at first made me laugh - TMON was the name of
the first machine language monitor I ever actually laid my mits upon; it was for my
(at the time) tape based Model I TRS-80. You can see why I laughed.
Nevertheless, TMQ promised some interesting things, like tracing ROM and
setting up to seven breakpoints. Also, they claimed that TMON was a multiple- window
monitor/debugger. Just the idea that a debugger could be multiple window boggled me.
The thing must be huge. E specially if it can disassemble, do hex dumps, heap displays,
register displays, and so on simultaneously.
The price looked pretty reasonable for all of this: the ad asked for $100.00,
which is less than I paid for MacASM, my assembler of choice. I finally broke down
and ordered TMON from TMQ. It arrived a few days after I ordered it; if you're willing
to pay for it, TMQ will ship UPS blue label, which is how I prefer to work.
After using TMON and configuring it and reconfiguring it and debugging some of
my own code and tinkering around with some code that I didn't write, I can make the
following observations.
Love at First Byte
First, if you don't already own a copy of TMON, run, don't walk, to get your
checkbook and order it now. If you are a serious developer (and if you are reading
this, chances are pretty good that you are) you should be using TMON. Use TMON once
and you'll never boot MacsBug again. I promise.
The ads really don't do it justice. They don't tell you about the interactive
assembler/disassembler; they don't tell you about the fact that dump and disassembly
windows can be "anchored" to registers and are continually updated; they don't tell you
that TMON allows access to any online resource file; they don't tell you about the
customizable user area; they don't tell you about the sophisticated label support, or the
screen buffering, or the rich implementation of interrupt button functions... The list
goes on.
Think of TMON as MacsBug and MacNosy combined, with some things thrown in
that neither MacsBug nor MacNosy was intended to do. To be fair about it, since
MacNosy is a disassembler and not a debugger, there are some features that MacNosy
has that TMON doesn't. I recommend both of them if you are serious about Mac
programming.
TMON's fast window system will impress you, as will its implementation of
menus. It takes a little getting used to; both windows and the menubar are handled a
little differently from "normal" Mac windows and menus.
Mouse Unfreeze
The menus are Dump, Asmbly, Brkpnts, Regs, Heap, File, Exit, GoSub, Step,
Trace, Options, Num, User, and Print. Another feature that TMON implements via a
command keystroke is called Mouse Unfreeze. Yes, you read right - if your program
crashes and your mouse freezes up but the keyboard is still listening, you can unfreeze
the mouse. Wild stuff.
Dump opens a window which is initially a dump starting at address 000000.
There is a blinking cursor on the first line. As long as the cursor is on the first line,
the address can be changed. You can type in any expression, label, or register to
anchor to (as well as a special virtual register called V). The window will be
instantaneously updated to show the new dump. More importantly, if you anchor to a
register (say A0), whenever the contents of A0 changes the window will be updated to
reflect the change. You won't believe how useful this is until you see it.
Disassembler Anchored to the PC Counter
'Asmbly' is the interactive assembler / disassembler. When you open this
window, you get a disassembly starting at 000000, which doesn't make much sense,
since there is no valid code there. You'll probably want to anchor the disassembly
window to the PC. Like the dump window, when you anchor the disassembly window to
a register it gets updated every time the register changes. Anchoring the disassembly
window to the PC causes the window to be updated every time you step, trace, gosub, or
exit to the program (actually, since exit actually transfers control to the program, the
window will not be updated unless control returns to the monitor).
TMON normally displays A-traps as labels, not numbers, although this can be
changed in order to conserve space. TMON also supports user-defined label tables. The
TMON master disk includes a file called System.MAP which is a label file of all of the
low memory equates on the Macintosh. This MAP file can be loaded into TMON so that
features of TMON that support labels (nearly all of them, in other words) can now
refer to low RAM areas (with labels like CurApName and so on) by name instead of
address. This aspect of TMON, unfortunately, requires 512K.
TMON includes sophisticated customization support that allows you to fine tune
TMON to your needs. TMON is quite capable of running on a 128K machine, and
contrary to what you might think, it does not have to be hopelessly crippled in order to
do so. I can use A-trap names and, with a compressed screen buffer of 4K, do some
meaningful debugging. A 512K Mac sure would help, though.
TMON has an alternate register save area. This is interesting. You can come
close to a routine that you think will crash, save the registers, execute the routine,
and if it crashes (an exception lands you back in TMON), you can reload the registers
and try again, and so forth. Kind of like being in suspended animation.
We all know that the interrupt button on the Mac is good for something. TMON
knows it, too. Pressing the button from an application will get you into TMON, just
like it does with MacsBug. However, there are several special-purpose
keystroke-interrupt combinations that TMON has over MacsBug.
Pressing interrupt while holding down the command key restarts the monitor.
This is considered a drastic step to be taken only when all else fails. This often has the
effect of mulching part of TMON. The nice thing is that TMON is constantly checking
itself, and if it thinks it's been damaged, it will say so.
Cmd-Option-Interrupt!
If that doesn't work, try command - option - interrupt. This does a really total
monitor reset, which makes it definitely last-resort material.
Now for the interesting one. The user area supplied with TMON contains a
function called Trap Signal. The manual calls the Trap Signal function a "smart
interrupt," which is a pretty apt description. Trap Signal allows you to specify a trap
or range of traps to apply this function to, as well as an optional address or address
range. Once you've done that, go ahead and execute your program.
Nothing happened, right? You're program should be whizzing merrily along.
Now press interrupt while holding down the option key. This activates the trap signal,
which won't go into effect until your trap and address range criteria are met. That's
why it's called a smart interrupt: it doesn't stop until it hits the right trap/PC
location. This allows you to interrupt your program at a specific place rather than
going into it blind. A good trap to put a smart interrupt on would be _GetNextEvent,
since it tends to be at the main loop of any Mac application.
Trace uses the Trace bit
TMON's trace, step, and GoSub features are very nice and very powerful. TMQ
Software saw fit to do what no one else did: they use the trace bit of the status register
to force a trace interrupt, which the monitor traps. This is the essence of tracing
under TMON. The trace function even allows you to watch as the A-trap dispatcher
finds the address of the A-trap's code and executes it. This means that my little note
concerning tracing the ROMs under MacsBug doesn't apply here; TMON's trace does it
automatically. Step in TMON is exactly like trace except that A-traps are treated as a
single instruction. GoSub is like step except that subroutines (executed by JSR or
BSR) are executed in full without tracing.
The heap windows are something else. Not only do they show what blocks exist
and whether the block is locked, purgable, relocatable, and what have you; they also
show what is in the block (to the best of TMON's ability). You can see at a glance which
block contains CODE segment number one of your program, which block contains the
font that is currently in use, which blocks contain resources pertinent to the
application, and so on. You can also examine the system heap in the same manner. A
heap window can be made to switch from appplication heap to system or vice-versa by
hitting the TAB key (which puts the cursor at the top of the window) and hitting the
RETURN or ENTER key.
The file window is extremely useful. It shows the contents of all currently open
resource files. For those resources that are in memory, their handle is given. For
those that haven't been loaded from disk yet, "Nowhere" is displayed. Resources of any
type and ID can be loaded using the standard user area LoadRes utility.
If a window is too limited to show you as much as you would like of what it is
you're looking at, you can probably print it with the user area print utility. You can
specify dump printing, disassembly printing, file printing, or heap printing. For
dumps and disassemblies you must specify an address range. For files TMON needs the
resource file number, and for heap prints it needs 0 for the system heap and a
non-zero value for the application heap.
There are lots of other handy features, too, such as block moves, block compares,
block fills, checksumming of memory, label table support, a very efficient heap
scramble, a find utility, the ability to show the application's screen, and the ability to
completely reset the system.
User Extensible via MDS
To make matters even better, the author includes the source code to the entire
default user area on the TMON disk. The point is that sophisticated Mac programmers
can write their own user area utilities that can either replace or augment the ones
included with TMON. The source is in MDS format, and a link file is included to link
the resulting object code into TMON. Obviously, you must have MDS for this to be of
any use. Frankly, I think it'll be a long time before anyone comes up with a way to
improve upon TMON's already fantastic user area routines.
That about wraps it up. My idea of an ideal Mac debugging setup is a 512K Mac
running TMON. Use the normal default user area, then add in the System.MAP file.
This will allow TMON to refer to low memory areas by name (which is handy if you're
doing ROM disassemblies in particular). Now you can really debug! Goodbye,
MacsBug; hello, TMON!
Referenced by (2):